1. Field of the Invention
The invention relates generally to communications between computer program objects and more particularly to a method of dynamic interface generation at an adapter manager and a service object, and further to a corresponding adapter manager and service object.
2. Description of Related Art
Computers are valuable assistants in an ever-growing number of fields. In the past computers were predominantly used for highly specialized applications, such as to support scientific work in research institutions, and thus were not highly proliferated. Today, virtually everyone uses computers for the widest range of applications. Applications include for example personal data services, office applications, e-mail, home banking applications, home shopping applications and similar.
Further, while in the early days application programs were usually executed on a single computer, today large networks of computers are often used for executing distributed applications, for example in client and server scenarios. Such application programs can be written as a single program, i.e., one piece of code. However, with the applications becoming ever more complex, writing a single program becomes very difficult. In many cases, writing a single program is most uneconomical, as often a number of different application programs or parts of application programs use similar functionality. Thus, computer programs are generally written in modules, which communicate with one another and exchange data in providing service to a user.
Structuring application programs into modules is facilitated by modern computer languages such as the C++ programming language, or any other object-oriented programming language, and by interface standards like CORBA or DECOM.
Object-oriented programming supports object technology, i.e., to structure an application program into individual objects. Typically, each object provides a certain functionality of the application program. For example, in a simple application program, an object realizes the functionality of a cursor on a screen, and this object interacts with further objects, for example objects providing functionality for drawing shapes and similar functionality.
To enable the objects, forming part of an application program or a plurality of application programs, to communicate with one another, i.e., to exchange data, interfaces between the individual objects must be available. These interfaces define the nature and format of data to be transmitted from one object to another object.
Generally, an object provides a plurality of such interfaces for communication with other objects. For example, to allow data transfer from one object to another object, the object (the requesting object) wishing to obtain service from the another object (the accessed object) requests a required interface from the another object to be accessed. Upon receiving the request, the accessed object provides the required interface.
In the prior art, the interfaces provided by an object formed an integral part of the object and were generally designed when originally writing the computer program code of the object. Thus, any capability of the object to communicate with the outside world, i.e. with other objects, was defined through the interfaces designed when writing the corresponding object.
Forming interfaces as an integral part of objects, however, means that in complex applications with a potentially very large number of interfaces, a large program overhead is generated, possibly replicating specific interfaces with different objects. Further, even if forming interfaces as an integral part of objects of an application program works well in a static environment, where access schemes between individual objects do not change, this may not work in a dynamic environment.
For example, consider a scenario where a plurality of application programs access a set of common objects. Some of the common objects are updated to a newer version and now require modified interfaces from the accessing applications. Different versions of the commonly accessing applications have to be provided. The different versions provide the required interfaces to the updated common objects and to the other common objects that were not updated.
Likewise, when one of the application programs is updated to a newer version and now requires modified interfaces from the commonly accessed objects, different versions of the commonly accessed objects have to be provided. The different versions of commonly assessed objects provide the required interfaces to the updated application programs and to the other application programs that were not updated.
Similar problems arise, if within a single application program a subgroup of the objects making up the application program are updated, leading to the requirement of different interfaces at accessed objects. This also leads to the requirement to provide different interface versions of objects, leading to high coding expenses and a large program overhead. Moreover, such problems arise when combining APIs (application program interfaces) such as Bonobo and OpenOffice.org, e.g. to access common objects.
Of course, instead of providing different versions of objects, the objects could be rewritten to satisfy all interface needs; however, this leads to the same disadvantages. Thus, all of the above examples share the disadvantage of either creating large numbers of derivations of object implementations or of creating a single or few implementations with a very large number of interfaces for all purposes.